Telephony web event system and method

ABSTRACT

An embodiment of the system for publishing events of a telephony application to a client includes a call router that generates events from the telephony application and an event router that manages the publication of events generated by the call router and that manages the subscription to events by clients. The system can be used with a telephony application that interfaces with a telephony device and an application server.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/241,746, filed 7 Jan. 2019, which is a continuation of U.S. patentapplication Ser. No. 15/709,905, filed 20 Sep. 2017, which is acontinuation of U.S. patent application Ser. No. 15/193,416, filed 27Jun. 2016, which is a continuation of U.S. patent application Ser. No.14/591,279, filed 7 Jan. 2015, which is a continuation of U.S. patentapplication Ser. No. 12/572,258, filed 1 Oct. 2009, which claims thebenefit of U.S. Provisional Application No. 61/102,007 filed on 1 Oct.2008, all of which are hereby incorporated in their entirety by thisreference.

TECHNICAL FIELD

This invention relates generally to the event notification field, andmore specifically to an new and useful system and method in thetelephony web event field.

BACKGROUND

In recent years, there has been a growing trend of both internet-enabledphones and “websites as software”. These two markets thrive on thetransfer of information, instantaneous communication, and interactionbetween remote devices. However, current systems do not provide aseamless integration of telephony actions with remotely hostedapplications, with server-side components, or with front-end websites.For instance, it is currently extremely difficult (if not impossible) torelay events that happen during a telephony call to or from a websitesecurely in real-time during the telephony call. In addition, separationof business logic from telephony components complicates the transfer ofrealtime events from the call infrastructure to other remote services.Thus, there is a need in the telephony field to create a new and usefultelephony web event system and method. This invention provides such anew and useful system and method.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is a schematic diagram of the preferred embodiment of theinvention.

FIG. 2 is a detailed schematic diagram of the preferred embodiment ofthe invention.

FIG. 3 is a flowchart diagram of a preferred method of eventsubscription for telephony applications.

FIG. 4 is a flowchart diagram of a preferred method of distributingevents.

FIG. 5 is a flowchart diagram of a preferred method of subscribing toevents.

FIG. 6 is a flowchart diagram of a preferred method of subscribing andpublishing events.

FIG. 7 is a flowchart diagram of a preferred method full duplexpublishing and subscribing of events.

FIGS. 8A-8C are examples of a HTTP GET request, a HTTP POST request, anda HTTP GET request, respectively.

FIGS. 8D-8F are examples of a HTTP requests.

FIGS. 9A and 9B are examples of XML responses.

FIG. 10 an example of subscription aggregation.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

The following description of the preferred embodiments of the inventionis not intended to limit the invention to these preferred embodiments,but rather to enable any person skilled in the art to make and use thisinvention.

1. Telephony Web Event System

As shown in FIGS. 1 and 2, the telephony web event system 100 of thepreferred embodiment includes a call router 110 and an event router 120.The system functions to enable real-time telephony event interaction. Inthe preferred system, telephony events (e.g., a dialing sequence, aspeech command, and a phone call termination) are sent out by apublisher (a device that prepares and electronically announces theoccurrence of an event, preferably a call router) and received by asubscriber. A subscriber is preferably any client 130, such as a webbrowser 132 or Application Programming Interface (API) server 134 thathas permission to receive information concerning a particular event. Thesystem 100 is preferably implemented on a multitennant system where aplurality of applications and users are handled on the same software orhardware system. In particular, the call router can preferablysimultaneously manage a plurality of telephony application and the eventrouter can publish a plurality of events and manage a plurality ofsubscriptions for a plurality of clients. The components of the systemare preferably scalable with respect to the number of accounts,in-progress calls, events on those calls, and the number of clientsubscriptions. Call routers 110, event routers 120, or any sub-elements(such as event proxy servers 122 or message brokers 128) may beallocated or deallocated to automatically adjust for capacityrequirements. A load balancer 121 may additionally be included tooptimize the operation of the system components.

The call router 110 of the preferred embodiment functions to initiatethe publication of events occurring during a telephony application. Thetelephony application is preferably a program controlling theinteraction between a telephony based device 112 and an internet basedweb application server 114. The call router 110 preferably controls thecall and program logic that enables telephony devices 112 to interfacewith the application server 114, as discussed in more detail below. Thecall router 110 preferably detects events occurring from the telephonyapplication 114 and publishes these events to the event router 120. Thecall router may additionally include an event distributor 116 thatdetermines to which event router to deliver the event. In one variation,the event router 120 includes a plurality of message brokers 128 thatmanage the publication of events. The message brokers 128 may be shardedor arranged according to event type or any suitable arrangement. Theevent distributor 116 preferably has control logic to know the correctmessage broker 128 to send an event. The control logic is preferablyupdated or synched with the scaling of hardware or software resources ofthe event router. As an example, an event may have varying attributes,such as account ID, a call ID, or event type. The message brokers 128may be sharded based on any of these attributes or any combination ofattributes. For example, if there are 3 event routers (shards), then,the call router could convert the call ID into an integer and thatnumber modulo 3 to determine which event router to contact. An eventproxy server 122 may additionally share this control logic such that theevent proxy server 122 knows which message broker(s) 128 to subscribeto. The event proxy server 122 preferably uses a similar technique todetermine which event router 120 to contact based on what attributeswhere subscribed to. Additionally an event may be distributed(published) to multiple message brokers 128, such as in the situationwhere an event has attributes that are managed by multiple messagebrokers 128. For example, the event may be published by one messagebroker 128 that manages publication of events for a particular accountand the event may additionally be published by a second message broker128 that manages publication of events of a particular event type.Additionally, multiple event distributor 116 may be allocated ordeallocated. The call router and the event router preferably communicateusing HTTP or alternatively HTTPS, though any suitable communicationsystem may be used. The published event preferably includes the accountto which the event belongs, the type of event, and optionally a set ofevent data related to the event.

The call router 110 of the preferred embodiment additionally functionsto initiate or receive calls from the telephony device 112 and connectto a web-application server 114. The call router 110 is substantiallysimilar to the call router disclosed in application Ser. No. 12/417,630filed on 2 Apr. 2009 and entitled “System and Method for ProcessingTelephony Sessions” which is hereby incorporated in its entirety by thisreference. The call router 110 is preferably connected to a PSTN deviceover the PSTN network, such that it can receive and make calls fromPSTN-connected devices 112, such as landlines, cellular phones,satellite phones, or any other suitable PSTN-connected devices, as wellas non-PSTN devices, such as Voice-Over-Internet-Protocol (VOIP) phones,SIP devices, Skype, Gtalk, or other Internet addressable voice devices.The call router 110 may alternatively or additionally function as orinclude a message router for use with message-based networks such asSMS, email, faxes, instant messaging, or micro-blogging networks. Thecall router 110 can preferably connect to an SMS network, such that itcan receive and send messages from SMS network devices 112, cellularphones, computers, smart phones, or any suitable SMS network devices.The call router 110 may also send or receive text messages, multimediamessages, emails, faxes and other suitable PSTN-compatible communicationmessages. The call router 110 can preferably connect to an instancemessaging network, such that the call router 110 can receive and sendmessages and receive and transmit presence information from differentinstance messages networks such as those based on protocols like Jabber,AIM, or fax. The call router 110 can preferably connect tomicro-blogging networks such as Twitter such that it can receive andsend messages to and from micro-blogging networks via APIs exposed bythose networks. The call router 110 may alternatively send and receivemessage from any suitable system with exposed APIs. The call router 110preferably communicates with the application server 114 using anapplication layer protocol, more preferably using the HTTP, or secureHTTPS, protocol. The communication between the application server 114and the call router 110 is preferably stateless and any stateinformation (e.g., call state) or data is preferably located in a URI orthe request parameters, such as HTTP headers, GET URI parameters, POSTrequest body parameters, or HTTP cookies. Available state information ispreferably transmitted by call router requests to the application serverfor stateless processing, and the application server preferably storesno state. Alternatively, the application server preferably stores localstate information, such as databases or sessions, as is common in webdevelopment. The call router 110 preferably stores state information incall router resources 29. The call router resources are preferablyaccessible by the application server 114 and other devices through acall router API. The call router 110 preferably associates each incomingphone number with a starting resource address (or more specifically aURI), more preferably the URI is provided by the application server 114,still more preferably the URI is provided by the application developerbefore a call is received at the call router 110 by associating theinitial URI with the incoming call address (such as DID, SIP address,etc.) or by the application upon initiation of an outgoing call. Thecall router 110 preferably sends call data such as the caller number(obtained via Caller ID), caller geographic data (country, city, and/orstate, zip), the number dialed, the time of the call, or any othersuitable information or parameter. The call data is preferably digitallysigned with a secret key stored on the call router 110. A cryptographichash of the information is preferably included along with theinformation as a digital signature. The call router 110 may also encryptsensitive information (either before or after the cryptographic hash iscomputed) using the secret key to allow sensitive information to be sentacross the network. The call data is preferably sent as an HTTP POSTrequest to the application server 114. Call data may also be sent in URL(GET) variables, or encapsulated in HTTP headers. An example HTTPrequest containing the information in the header as shown in FIGS. 8Aand 8D. As shown in FIG. 8B, further inputs (such as voice recording orDTMF button pressing) from the PSTN-device may be subsequently submittedto the application server 114 as HTTP requests (GET or POST). As shownin FIG. 8C, the inputs from a phone keypad may be included in an HTTPGET request. As shown in FIG. 8E, the content of an SMS message receivedby the call router may be sent to the application server 114 as an HTTPrequest. As shown in FIG. 8F, the inputs from the text message areincluded in an HTTP GET request. The request data may alternatively besimultaneously sent in the URI (query string), message body (POST) andmessage headers, or any combination of the above.

Any suitable action or parameter, either initiated by the telephonydevice 112 or by the application server 114, may constitute an eventgenerated by the call router 110. The call router 110 preferablyautomatically detects such events through any suitable program logic.Events may relate to call related events such as starting or ending acall, starting or ending dialing a number, or any call based occurrence.The events may additionally or alternatively be related to telephonyactions such as starting or stopping recording audio, starting orstopping a Text-To-Speech (TTS) conversion, starting or stopping theplaying of an audio file, beginning or stopping the gathering oftelephony input, redirecting the call to another phone number, or anytelephony based instruction. Events may additionally be adjusted forparticular applications such as conference calls. Conference call eventsmight include a participant joining a call, a participant leaving acall, gathering telephony input, participant muted, participant unmated,or any suitable conference based event. Furthermore, events may begenerated for actions that occur on the message-based protocols used bythe call router 110. For example, an messaging events might include amessage sent, message received, and message error for SMS, email, faxes,instant messaging, or micro-blogging messages.

The event router 120 of the preferred embodiment functions to connectpublished events with subscribers of the event. Preferably, thepublished event, is pushed to subscribers through an open HTTPconnection (a single continuous HTTP connection). The open HTTPconnection functions to simplify software of a web application using thesystem. Alternatively, the connection may push data with HTTPS,intermittent HTTP/HTTPS connections, AMF Channel, TCP connection. UDPconnection, chat protocols such as jabber, or any suitable messagingframework. The event router is preferably a server, which may bepartitioned and scaled for greater capacity. The event router 120 mayalternatively be a monolithic system or any suitable software orhardware device(s) for routing events between any number of eventpublishers and authorized subscribers. In one preferred embodiment, theevent router includes an event proxy server 122 and/or a message broker128. The event proxy server 122 preferably manages the subscriptionsfrom a client (i.e., subscriber) and/or performs more computationalintensive processes like filtering events and security. The messagebroker 128 preferably manages the publications and more preferablymanages a subset of event publications from the call router. The eventproxy server 122 is preferably part of a cluster of event proxy servers122 that can be dynamically scaled to satisfy capacity requirements. Themessage broker 128 is preferably part of a cluster of message brokers128 that can similarly be dynamically scaled to satisfy capacityrequirements. A load balancer may additionally be included within theevent router 120 to manage the capacity load of the various components(e.g., the event proxy servers 122 and the message brokers 128). Aplurality of load balancers may be individually implemented for eachcomponent type, or a single load balancer may manage the event router120.

The message broker 128 of the event router 120 functions to manage tirepublication of events. The message broker 116 (or core messagedistributor) preferably handles routing of events to be published. Amessage broker is preferably any message broker as is known in the artsuch as RabbitMQ or other Advanced Message Queuing Protocol (AMQP) basedbroker. Preferably, a plurality of message brokers 128 is used to managethe events. More preferably message brokers 128 are sharded (i.e.,partitioned) according to dedicated event types (or group of eventtypes). Events are preferably distributed to the appropriate messagebroker 128 based on the event type. The sharding of message brokers mayalternatively be according to any suitable rule. The message brokers 128(i.e., the shards) may additionally be hosted on different hardware orsoftware platforms, and event type responsibilities may be adjusted whenadditional message brokers 128 are allocated or deallocated from thecluster of message brokers 128. The message broker 128 may alternativelybe a single device for all published events or hosted on a singlesystem. A message broker 128 preferably sends events to an event proxyserver 122 that is subscribed to a particular event. A message broker128 may additionally send an event for any number of subscriptions,where the subscriptions are managed by any suitable number of eventproxy servers 122.

The event proxy server 122 of the event router 120 functions to managethe subscriptions of clients. The client preferably connects to theevent proxy server 122 for establishing a subscription to an event andto receive notification of events being published through the eventrouter 120. Events published by a message broker 128 are preferablydistributed to a subscribed event proxy server 122, and the event proxyserver 122 preferably sends the event to a client. The event proxyserver 122 is preferably part of a plurality of event proxy servers 122that can be automatically scaled. Additionally, an event proxy serverpreferably manages multiple subscriptions, and may subscribe to multiplemessage brokers 128. Additionally, a plurality (or series) of eventproxy servers 122 may be connected to a single message broker 128 or anysuitable device publishing the event for the event router 120. Theplurality of event proxy servers 122 functions to increase the volume ofsubscriptions the event router 120 can manage. A plurality of eventproxy servers 122 may alternatively be used with a partitioned messagebroker 128, multiple message brokers 128, or any suitable configuration.As another variation, an event proxy may have multiple subscriptions(e.g., for different clients) to a message broker 128. This multiplesubscriptions may have redundancies. The event proxy server 122 mayaggregate the subscriptions for improved system efficiency, as shown inFIG. 10. The event distributor 116, the message brokers 128, and theproxy servers 122 cooperate to increase the subscription capabilities ofthe event router. The event proxy server 122 additionally functions toperform resource intensive processes such as running an event filter orsecurity policy engine. The event proxy server 122 is preferably adedicated server for handling event filtering, operating the securitypolicy engine, and/or any suitable CPU intensive tasks.

The event router 120 of the preferred embodiment may additionallyinclude an event filter 124 that functions to selectively pass events toa client. The event filter 124 is preferably operated on an event proxyserver 122. Event filters 124 selectively filter the number of eventspublished to a particular subscriber based on account security, eventtype, contents, and/or any suitable parameter of the event. When asubscriber issues a subscription request, the request preferablycontains a set of credentials and more preferably a set of eventfilters. The event router 120, more preferably the event proxy server122, first verifies the account ownership via the credentials todetermine if the subscriber is authorized to view events for the givenaccount. Once a subscriber's identity is determined, the event routeronly passes events that are associated with authorized accounts.Preferably, this account-level security preferably limits visibility ofevents to only the relevant account or accounts, and the event filtersare preferably applied after the account-level security. The event proxyserver 122 preferably applies the event filters 124 to determine if theevent router should publish an event to a given subscriber. The eventfilter 124 is preferably a type filter or a parameter filter. A typefilter preferably filters event details by the type of event such as‘call start’, ‘call end’, ‘call error’, ‘call warning’, ‘record start’,‘record end’, ‘gather start’, ‘gather end’, ‘dial start’, ‘dial end’and/or any suitable type of event. A parameter filter preferably filtersevents based on characteristics of the event such as by caller ID,contents of call, time of call, duration of call, area code of call,and/or any suitable characteristic of a call. A parameter filter mayadditionally filter based on the event (such as which digit was pressedby the caller, the warning message issued by the call router, or thelength of a recording). Event filters 124 may be used in a variety ofways. As one example, filters may be configured to subscribe to aparticular call. As another example, the filters may be configured tosubscribe to all calls to and/or from a given phone number. As yetanother example, the filters may be configured to subscribe to aparticular telephony application action such as “call start” across anaccount (which may involve multiple simultaneous calls for various phonenumbers). The event filter 124 may additionally function to provide alevel of security. The event filter 124 preferably prevents inspection,observation, receiving, and/or gathering of any useful informationconcerning a subset of events. A publisher may implement a securityevent filter 124 for events the publisher does not want a subscriber tosee or alternatively, any suitable entity may implement a security eventfilter 124.

The event router 120 of the preferred embodiment may additionallyinclude a security policy engine 126 that functions to enforce asecurity policy governing which subscribers are allowed to subscribe toa particular event. The event proxy server 122 preferably operates thesecurity policy engine 126. Preferably, the security policy engine 126includes a signed URL. The signed URL is preferably composed of asubscription message and a verification token. The verification tokenfunctions to be validation of the authenticity of the subscriptionrequest. A private key shared between the client application developerand the event router is preferably used to generate the verificationtoken and is preferably a code, password, or any suitable identifier.The verification token is preferably implemented as an HMAC (HashMessage Authentication Code) hash using the key, but may alternativelybe implemented by any suitable cryptographic message authenticationtechnique. The verification token preferably includes the subscriptionrequest including a subscription URL, subscription filters, subscriptionexpiration time, and/or any other suitable subscription metadata orparameter. The verification token is preferably attached to thesubscription request. In one preferred version, the verification tokenis appended to the end of a URL of the subscription message to form thesigned URL. The signed URL allows the subscription request to be passedto unknown devices, such as a remote web browser, and allowing thebrowser to issue subscription requests without knowing the key or otherinformation. Alternatively, other security systems such as OAuth URLsigning or any suitable security method may be implemented.

The system of the preferred embodiment may also include a connection tothe client device 130, which functions to be a channel through whichpublished events that a client subscribes to can be delivered. Theconnection 130 is preferably any suitable network connection eitherwired or wireless. The connection 130 is preferably between an eventrouter 120 and the client, and more preferably, the connection 130 isbetween an event proxy server 122 and the client. The connection to theclient is preferably an HTTP connection but may be any suitablesignaling protocol. The client device of the preferred embodimentfunctions to provide interaction with subscribed events. The clientdevice may be a front-end interface of the web application. The clientdevice preferably reacts to events and provides an interface for userinteraction. The client device may be a website, a computer program, aweb enabled consumer product, a server, or any suitable device. However,the client device may alternatively be a backend system such as a datacollection system. A browser 132 is one common type of client. Aconnection with a browser is preferably implemented via Ajax injavascript (e.g., XMLHttpRequest) or via a flash plugin (e.g., XMLSocketor an AMF or SecureAMP channel). An Application Programming Interface(API) server 134 is a second common type of client. A client preferablyinitiates the creation of connection 130 to the event router 122.However, in the situation of an API server 134, the event router 120 or,more preferably, an event proxy server 122 may initiate the creation ofa connection 130 to the client 130. There may additionally be a controlchannel and a publication channel. The control channel is a connectionthrough which a client submits a subscription request. The client canmanage subscriptions through the control channel. Management ofsubscription includes modifying an existing subscription (e.g., updatingfilters or changing expiration time), adding a subscription, deleting asubscription and/or any suitable subscription change. The subscriptionchannel is the connection through which events are sent to the client.In one variation, a client may setup multiple subscriptions and/ormodify subscriptions through multiple control channels or alternativelythrough one control channel at different times. One publication channelis preferably used regardless of the number of subscriptions of aclient. This functions to reduce the number of open connection 130between the client and the event proxy server 122. The connection 130may be any suitable connection as mentioned above. In the case where theconnection is a long poling type connection, a client preferablyconnects to the event proxy server 122, gets an event, and closes aconnection. When the client is not connected, events may be missed bythe client. The event proxy server 122 preferably includes a cache tostore events (up to an expiration time) and delivers the cached eventsto the client during the next connection with the client.

The application server 114 of the preferred embodiment functions toprovide a web developer with an improved development environment forinterfacing and designing interactions for communications applications.The call router 110 preferably manages the interaction between thetelephony device(s) 112 and the application server 114. Events arepreferably generated by this interaction. The web application(application server) is preferably a website, but may alternatively be acomputer program, a web enabled consumer product, or any suitable methodor device capable of event subscription tasks. The application server114 preferably combines telephony actions and a website to form apowerful user experience. In one example of an application server 114, auser may enter a phone number and leave audio comments for individualphotos as the photos cycle through a slideshow. In a second example, aconference call can be managed through a web interface. In a thirdexample, a customer service phone call may be managed and annotatedusing a web interlace. In a fourth example, a business or sales phonecall may be managed and supported by using a web interface. Any suitableapplication server utilizing telephony interaction may alternatively beused. The web application is preferably programmed in a manner similarto regular websites, but integration into the system allows for new userexperiences relying on telephony actions.

The application server 114 functions to provide data processing logicfor requests received from the call router 110. The application server114 is preferably connected to the call router 110 via a network 24,more preferably via the Internet. The application server 114 ispreferably a third party server operated outside of the system, but thesystem may alternatively include the application server 114. A URI ispreferably associated with an application server 114 or an applicationon an application server 114. The application server 114 preferablycommunicates with the call router 110 using an application layerprotocol, more preferably using the HTTP protocol, or more secure HTTPSprotocol. The application server 114 preferably receives HTTP requestsfrom and sends HTTP responses to the call router 110. The applicationserver 114 preferably runs on a standard stack of programming languages,hosting providers, operating systems and databases to handle HTTPrequests, as if the caller were a website visitor in a web browser. Theapplication server 114 also preferably verifies the digital signaturesof the call data received in the requests using the secret key tocompute a cryptographic hash from the received information and the hashreceived. If the computed hash and the received hash do not match, or nohash is received with the request, then the application server 114preferably determines the request is fraudulent, and the request ispreferably discarded. If the computed hash and received hash match, theapplication server 114 preferably determines that the request isauthentic and proceeds further with the processing of the request. Theapplication server may alternatively choose to ignore the hash ifsecurity is not important. The application server preferably uses callstate data communicated by the call router request to determine the nextcall router instructions, without requiring call state stored on theapplication server. The application server may alternatively use callstate data sent by the call router, such as the caller ID of the calleror the unique ID of the call, to reference additional or external statedata, such as rows in a database or session data stored on theapplication server.

The application server 114 preferably responds to HTTP requests receivedfrom the call router 110 by generating telephony instructions for thecall router 110. Telephony instructions when executed by the call routerpreferably cause an event to be detected by the call router 110. Theapplication server preferably replies to the call router in XML,however, any suitable machine-readable message format may be used,including HTML, key/value pair text, delimited text or binary encoding.The XML preferably includes the telephony instructions for the callrouter 110 such as connecting to another number, playing a recordedgreeting, reading text, and/or requesting DTMF digit entry from thecaller. The telephony instruction may alternatively be related to SMSmessaging, Multimedia Messaging Service (MMS) messaging, faxes, instantmessages, email, micro-blogging, or any suitable messaging task. Thetelephony instruction may additionally be used to send an outgoing SMSmessage, arrange a phone call from a specific phone number, arrangingfor a callback, setting up a conference call (connecting multiplenumbers), sending an email, interfacing with a calendar or schedulingsystem, purchasing goods, or services, or any other suitableinstruction. The XML instructions are preferably a set of commands to beexecuted in order, one at a time (i.e., sequentially). An example XMLresponse is shown in FIGS. 9A and 9B. In single telephony session (e.g.one initiated by a PSTN-device or an SMS device), a response from anapplication server can initiate an outgoing telephony call and/or a SMSmessage. That is, a single XML response preferably provides the abilityto interact with both the SMS network and the voice telephony network(PSTN, SIP/VoIP, etc) sequentially or simultaneously. In addition, audioor video files sent to the call router 110 can be converted to text byan automatic speech-to-text engine, human or other technique, and sentback in text form as an SMS message or an attachment to an MMS. In onevariation, an application running on a server may be a simple static XMLpage and static sound files, deployed on basic web servers where nodevelopment or scripting environment is available. This variationpreferably uses URI Templates (a current IETF proposal for HTML5), whichessentially includes URLs with placeholders for variable data, likethis: http://www.twilio.com/audio/{Digit}.mp3 where the call router 110would substitute the digits pressed for the {Digit} placeholder in theURI Template, GET the file at the resulting URI, and play the staticsound file in response. This allows an entire application to be authoredoffline in a What-You-See-Is-What-You-Get (WYSIWYG) html editor. Forexample, if the server response specifies the URI Template:http://demo.twilio.com/myapp/{Digits}.mp3, and the caller presses digits1234, the call router 110 would GET the static mp3 file located at:http://demo.twilio.com/myapp/1234.mp3 and play it to the caller. Thevariables used for substitution in the URI Templates preferablycorrespond to the names of variables defined for state submission inHTTP GET, POST and/or header requests from the call router. From theprevious example, {Digits} would be associated with a parameter named“Digits” that is preferably generated as a result of a “gather”telephony instruction (collection of DTMF digits). In the preferredembodiment for the second configuration, the call is initiated by theapplication server 114 (through the call router 110), and the secondconfiguration is substantially similar to the first configuration, suchthat the call routing is preferably handled identically to an incomingcall, namely via URI requests from call router 110 to the server 114upon call state changes.

As an additional alternative, the system may be implemented to be fullduplex where events (client events) may additionally be published from aclient and the call router can subscribe to the client events as shownin FIG. 7. In this alternative, the event router additionally managesthe publication of client events and manages call router subscriptionsto client events. The system is preferably implemented in substantiallythe same way as above, but with the client additionally generatingevents and the call router subscribing to events. The client eventsystem is preferably integrated with the eventing system describedabove.

2. Telephony Web Event Method

As shown in FIGS. 3-6, the method of event subscription for telephonyapplications includes distributing events S100 and subscribing to eventsS200. Distributing events preferably includes the sub-steps publishingan event to a router S110, identifying subscribers to an event S120, andsending an event to a subscriber S130. Subscribing to events includesthe sub-steps of generating a signed URL for an event subscription S210,sending an event subscription request to an event router S220, verifyingan event subscription S230, and allowing an event subscription S240. Themethod may additionally include allocating new resources to the eventrouter. In particular event proxy servers and message brokers may beallocated or deallocated. Additionally, call routers, eventdistributors, and/or any suitable part device of the system may beallocated or scaled to accommodate capacity needs. A load balancer mayadditionally distribute processing across the plurality of components.

As an alternative, the method may additionally include receiving asubscriber generated client event, publishing the client event to theevent router and identifying a call router subscribed to a client event,and sending the client event to the call router. This functions to makethe eventing method full duplex for two way event publication andsubscription. The duplex eventing system is substantially similar to theeventing system described, but where the client generates the events andthe call router is subscribed to the events.

2A. Method of Publishing an Event

Step S110, which includes publishing an event to a router, functions toinitiate the announcement of an event. Event details are preferably sentto an event router at a URL or other suitable resource or connectionidentifier. Event details preferably include account identification,event type, any event data associated with the event, and any othersuitable parameters relating to the event. Publishing to a routerpreferably occurs after a new event occurs, but alternatively, a batchof events may be published periodically, a batch of events may bepublished when an event count is satisfied, an event may be publishedwhen an event type is satisfied, or any suitable event publishing rulemay be applied. An event is preferably generated from a telephonyapplication operating on a call router. The telephony application ispreferably substantially similar in functionality to the one describedabove. A call router preferably publishes an event to an event router.The event is preferably published over HTTP, but any suitable protocolmay be used. An event distributor may additionally select a messagebroker to send the event. A plurality of message brokers may be shardedaccording to event types and the event distributor preferably is capableof mapping the event to the appropriate message broker.

Step S120, which includes identifying subscribers to an event, functionsto identify all authorized subscribers that should be notified that theevent occurred. The subscribers are preferably associated with asubscription URL. Any suitable number of subscribers is preferablyidentified, and subscribers are preferably identified by inspecting alist of subscribers. The subscribers may alternatively be associatedwith a group of other subscribers, and a group (or groups) may beidentified as a subscriber. Identifying subscribers is preferablyperformed by an event router, and more preferably an event proxy serverin cooperation with a message broker, though any suitable device may beused. Preferably, an event proxy server performs the steps of managing asubscription of a client (subscriber) and subscribing to an eventpublication of the event router. The event proxy server preferablysubscribes on behalf of a client, so that subscription processing can bedelegated to the event proxy server. More preferably a message brokerperforms the steps of publishing the event. So that the event proxyserver subscribes to a message broker. Identifying subscribers of anevent may include a sub-step of verifying event filters. Anaccount-level security may additionally be enforced by the event routerto limit the visibility of events to only relevant accounts. The eventis compared to filters of a subscriber to ensure the subscriber shouldbe sent the event. The filters are preferably type filters or parameterfilters as discussed above.

Step S130, which includes publishing an event to a subscriber, functionsto notify a subscriber of the occurrence of an event. The event ispreferably published by an event router over an open HTTP connection,but alternatively, a periodic HTTP connection, messaging framework suchas Jabber, or any suitable communication protocol may be used. In thesituation where a client has previously broken a connection with theevent router (i.e., is not connected to the event router at the time anevent occurs), the event proxy server preferably establishes aconnection to the subscriber. The event proxy server preferablyestablishes the connection by accessing the stored address of the clientand connecting through any suitable protocol. In the case the subscriberis an API server, an API command may be used to connect or notify theAPI server of the event.

2B. A Method of Subscribing to an Event

Step S210, which includes generating a signed URL for an eventsubscription, functions to generate a URL encoding any subscription URL,filter, and/or identification information. An unsigned URL is preferablygenerated including account identification, subscription URL,subscription filters, subscription expiration time, and/or any othersuitable subscription metadata or parameter. Preferably, a key is lookedup based on the account identification. The key is used to create averification token. The verification token Ls preferably implemented asan HMAC-SHA1 (Hash Message Authentication Code) hash using the key orany suitable another cryptographic message authentication technique maybe used. The verification token additionally includes the subscriptionrequest including a subscription URL, subscription filters, subscriptionexpiration time, and/or any other suitable subscription metadata orparameter. The verification token is preferably appended to the unsignedURL to form a signed URL. The signed URL is preferably integrated into asubscription request. The subscription request is preferably a requestto receive particular events of a telephony application.

Step S220 includes sending a subscription request to an event router.The subscription request is preferably sent to an event router by HTTPprotocol, but any suitable protocol may alternatively be used. Thesubscription request is preferably received by an event router, and morepreferably is received by an event proxy server. The event proxy serverpreferably manages subscriptions.

Step S230, which includes verifying an event subscription, functions toverify the identity of a subscriber. The signed URL of the event ispreferably deconstructed to identify account identification,subscription URL, subscription filters, subscription expiration time,and/or any other suitable subscription metadata or parameter. The eventrouter preferably verifies that the account identification is includedin the signed URL or other authentication credentials. If no accountidentification is found, the subscription request is discarded and anerror is returned. If the identification information is included a keyfor the account is looked up (i.e. found in a database). The key ispreferably a shared key that is identical to the key of Step S210. Thekey is then used to form a verification token. The verification token ispreferably a HMAC hash, or alternatively any suitable cryptographicmessage or identifier. The verification token is compared to theverification token from the signed URL to verify the match.

Step S240, which includes allowing an event subscription, functions toallow a client to subscribe to an event. A subscription preferablyallows a client to receive events in real time (approximately a fewmilliseconds to a few seconds). An event subscription also only allowsevents that are authorized to be viewed by the account, such as eventsgenerated by calls on that account. More preferably, the eventspreferably pass any filters of a subscriber. As an additionalalternative, subscriptions may expire after a given time. As part ofStep S240, the method includes the event proxy server (or event router)configuring filters for the subscription. This step functions to setupprocessing operations of the subscription. Additionally, any suitablesubscription setup that must be performed is additionally performed. Inthe variation where the subscriber previously has a subscription, theprevious subscription may be modified to include the new subscriptiondetails. Events from multiple subscriptions of one subscriber arepreferably sent to the subscriber through a single connection asdescribed above. In the situation where a subscriber is not connected tothe event router when an event occurs the event proxy server or anysuitable device may queue or cache the events for delivery when thesubscriber next establishes a connection.

As a person skilled in the art will recognize from the previous detaileddescription and from the figures and claims, modifications and changescan be made to the preferred embodiments of the invention withoutdeparting from the scope of this invention defined in the followingclaims.

We claim:
 1. A method comprising: receiving, at a telephony system, anapplication instruction of an application server that is external to thetelephony system, the application instruction received using anapplication programming interface (API) via a network; in response tothe application instruction, performing a telephony action; publishingan event corresponding to the telephony action to an event router of thetelephony system; and sending the published event from the event routerto a subscriber.
 2. The method of claim 1, wherein: the applicationinstruction is a telephony instruction; the performing of the telephonyaction causes the event to occur; the telephony instruction is aninstruction of an account of a plurality of accounts of the telephonysystem; and the event is an event of the account.
 3. The method of claim1, further comprising: before receiving the application instruction, bythe telephony system, establishing a subscription by the subscriber forevents associated with a type of the published event.
 4. The method ofclaim 1, further comprising: sending the published event to theapplication server.
 5. The method of claim 1, wherein the applicationinstruction is an instruction to dial a phone number.
 6. The method ofclaim 1, wherein the telephony action comprises dialing a number.
 7. Themethod of claim 1, wherein the telephony action comprises starting aText-To-Speech conversion.
 8. The method of claim 1, wherein thetelephony action comprises playing an audio file.
 9. A telephony systemcomprising: a memory that stores instructions; and one or moreprocessors configured by the instructions to perform operationscomprising: receiving an application instruction of an applicationserver that is external to the telephony system, the applicationinstruction received using an application programming interface (API)via a network; in response to the application instruction, performing atelephony action; publishing an event corresponding to the telephonyaction to an event router; and sending the published event from theevent router to a subscriber.
 10. The telephony system of claim 9,wherein: the application instruction is a telephony instruction; theperforming of the telephony action causes the event to occur; thetelephony instruction is an instruction of an account of a plurality ofaccounts of the telephony system; and the event is an event of theaccount.
 11. The telephony system of claim 9, wherein the operationsfurther comprise: before receiving the application instruction,establishing a subscription by the subscriber for events associated witha type of the published event.
 12. The telephony system of claim 9,wherein the operations further comprise: sending the published event tothe application server.
 13. The telephony system of claim 9, wherein theapplication instruction is an instruction to dial a phone number. 14.The telephony system of claim 9, wherein the telephony action comprisesdialing a number.
 15. The telephony system of claim 9, wherein thetelephony action comprises starting a Text-To-Speech conversion.
 16. Thetelephony system of claim 9, wherein the telephony action comprisesplaying an audio file.
 17. A non-transitory machine-readable medium thatstores instructions that, when executed by one or more processors of atelephony system, cause the telephony system to perform operationscomprising: receiving an application instruction of an applicationserver external that is to the telephony system, the applicationinstruction received using an application programming interface (API)via a network; in response to the application instruction, performing atelephony action; publishing an event corresponding to the telephonyaction to an event router; and sending the published event from theevent router to a subscriber.
 18. The machine-readable medium of claim17, wherein: the application instruction is a telephony instruction; theperforming of the telephony action causes the event to occur; thetelephony instruction is an instruction of an account of a plurality ofaccounts of the telephony system; and the event is an event of theaccount.
 19. The machine-readable medium of claim 17, wherein theoperations further comprise: before receiving the applicationinstruction, establishing a subscription by the subscriber for eventsassociated with a type of the published event.
 20. The machine-readablemedium of claim 17, wherein the operations further comprise: sending thepublished event to the application server.